개요

디플로이먼트에서도, 파드의 컨테이너 프로브를 통해서도 현재 컨테이너의 준비 상태에 대한 조건을 걸 수 있다.
이 둘은 서로 상충될까? 어떤 관계를 가질까?
관련한 실험을 해보자.

minReadySeconds과 readinessProbe 설정

readinessProbe만 설정

일단 이렇게, 레디하는데 걸리는 시간을 지정해준다.

10초가 걸리도록 해두어서 대충 10초가 넘어가야만 레디 상태로 바뀌는 게 확인된다.
레디가 되지 않으니, available도 되지 않았다.

minReadySeconds는

디플 쪽의 세팅만 해봤을 때는, 레디 상태가 되기는 하지만 available에서 업데이트가 되지 않는다.
파드 자체가 이미 ready 상태이기에 트래픽을 정상적으로 처리할 수 있었다.
명확하게 서비스 엔드포인트가 생성되는 것을 확인했고, 포트포워딩으로 확인할 수 있었다.

그러나 available이 안 됐기 때문에, 만약 새로운 버전을 배포한다고 하면 available될 때까지의 시간이 소요된다.
버전 업데이트 과정에서 available이 되는 것을 확인하며 진행하기 때문에 그렇다.

동시 설정하면 어떻게 될까?

이번에는 둘 다 10초로 설정하고 진행했다.
먼저 10초를 기다리고 나서 파드가 ready 상태가 됐고, available은 10초를 더 기다려서야 상태가 바뀌었다.

둘은 상충하거나, 같은 부분을 건드리는 설정이 절대 아니라는 것이다.
아니 이거 변화하는 상태를 사진으로 어떻게 담음? ㅋㅋ
![[스크린캐스트 2024-12-26 17-56-36.webm]]
는 그냥 짤 따서 담으면 되는 부분이었구요..
보다시피 20초가 지나야만 available이 활성화된다.

결론

readinessProbe는 그냥 알고 있는 정도의 능력을 가진다.
즉, 파드의 레디 상태를 나타내기 위한 지표일 뿐인 것이다.

minReadySeconds는 업데이트에 영향을 주는 available에 대한 제한을 거는 기능이다.
그러나, 이때 파드의 ready 상태가 체크된 이후부터 동작한다.
즉 디플로이먼트는 파드의 Ready 상태를 우선 고려하며, 여기에 minReadySeconds 만큼의 시간을 추가적으로 기다리며 업데이트가 가능한지 따진다.

이 글은 명확하게 틀린 글이라고 할 수 있다..^[1]
일단 minReadySeconds는 파드에 트래픽을 보내는데 아무런 영향이 없다.
당연히 파드의 레디 상태를 체크하는 데에도 도움이 되지 않는다.
rollout process가 진행되지 않는다는 말만 맞는 것이다.

참고